Add `isPlatformVersionAtLeast` and `isOSVersionAtLeast` symbols #138944

madsmtm · 2025-03-25T20:06:20Z

Motivation

When Objective-C code uses @available(...), Clang inserts a call to __isPlatformVersionAtLeast (__isOSVersionAtLeast in older Clang versions). These symbols not being available sometimes ends up causing linker errors. See the new test tests/run-make/apple-c-available-links for a minimal reproducer.

The workaround is to link libclang_rt.osx.a, see e.g. alexcrichton/curl-rust#279. But that's very difficult for users to figure out (and the backreferences to that issue indicates that people are still running into this in their own projects every so often).

For another recent example, this is preventing rustc from using LLVM assertions on macOS, see #62592 (comment) and #134275 (comment).

It is also a blocker for setting the correct minimum OS version in cc-rs, since fixing this in cc-rs might end up introducing linker errors in places where we weren't before (by default, if using e.g. @available(macos 10.15, *), the symbol usually happens to be left out, since clang defaults to compiling for the host macOS version, and thus things seem to work - but the availability check actually compiles down to nothing, which is a huge correctness footgun for running on older OSes).

(My super secret evil agenda is also to expose some variant of @available in Rust's std after rust-lang/rfcs#3750 progresses further, will probably file an ACP for this later. But I believe this PR has value regardless of those future plans, since we'd be making C/Objective-C/Swift interop easier).

Solution

Implement __isPlatformVersionAtLeast and __isOSVersionAtLeast as part of the "public ABI" that std exposes.

This is insta-stable, in the same sense that additions to compiler-builtins are insta-stable, though the availability of these symbols can probably be considered a "quality of implementation" detail rather than a stable promise.

I originally proposed to implement this in compiler-builtins, see rust-lang/compiler-builtins#794, but we discussed moving it to std instead (Zulip thread), which makes the implementation substantially simpler, and we avoid gnarly issues with requiring the user to link libSystem.dylib (since std unconditionally does that).

Note that this does not solve the linker errors for (pure) #![no_std] users, but that's probably fine, if you are using @available to test the OS version on Apple platforms, you're likely also using std (and it is still possible to work around by linking libclang_rt.*.a).

A thing to note about the implementation, I've choosen to stray a bit from LLVM's upstream implementation, and not use _availability_version_check since it has problems when compiling with an older SDK. Instead, we use sysctl kern.osproductversion when available to still avoid the costly PList lookup in most cases, but still with a fall back to the PList lookup when that is not available (with the PList fallback being is similar to LLVM's implementation).

Testing

Apple has a lot of different "modes" that they can run binaries in, which can be a bit difficult to find your bearings in, but I've tried to be as thorough as I could in testing them all.

Tested using roughly the equivalent of ./x test library/std -- platform_version on the following configurations:

macOS 14.7.3 on a Macbook Pro M2
- aarch64-apple-darwin
- x86_64-apple-darwin (under Rosetta)
- aarch64-apple-ios-macabi
- x86_64-apple-ios-macabi (under Rosetta)
- aarch64-apple-ios (using Xcode's "Designed for iPad" setting)
- aarch64-apple-ios-sim (in iOS Simulator, as iPhone with iOS 17.5)
- aarch64-apple-ios-sim (in iOS Simulator, as iPad with iOS 18.2)
- aarch64-apple-tvos-sim (in tvOS Simulator)
- aarch64-apple-watchos-sim (in watchOS Simulator)
- aarch64-apple-ios-sim (in visionOS simulator, using Xcode's "Designed for iPad" setting)
- aarch64-apple-visionos-sim (in visionOS Simulator)
macOS 15.3.1 VM
- aarch64-apple-darwin
- aarch64-apple-ios-macabi
macOS 10.12.6 on an Intel Macbook from 2013
- x86_64-apple-darwin
- i686-apple-darwin
- x86_64-apple-ios (in iOS Simulator)
iOS 9.3.6 on a 1st generation iPad Mini
- armv7-apple-ios with an older compiler

Along with manually inspecting the output of version_from_sysctl() and version_from_plist(), and verifying that they actually match what's expected.

I believe the only real omissions here would be:

aarch64-apple-ios on a newer iPhone that has sysctl available (iOS 11.4 or above).
aarch64-apple-ios on a Vision Pro using Xcode's "Designed for iPad" setting.

But I don't have the hardware available to test those.

@rustbot label O-apple A-linkage -T-compiler -A-meta -A-run-make
try-run: apple

rustbot · 2025-03-25T20:06:26Z

r? @Amanieu

rustbot has assigned @Amanieu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot · 2025-03-25T20:06:29Z

This PR modifies run-make tests.

cc @jieyouxu

triagebot.toml has been modified, there may have been changes to the review queue.

cc @davidtwco, @wesleywiser

Amanieu · 2025-04-03T19:30:59Z

r? @tgross35

tgross35 · 2025-04-03T19:59:14Z

Happy to review the implementation, but @Amanieu mind confirming you are okay providing these symbols from std? It seems reasonable to me but as far as I know we don't have anything like this. (Also no other builtins that effectively need std API).

Allows users to link to Objective-C code using `@available(...)`.

Based on findings in rust-lang/rust#138944, we were previously incorrectly falling back to the product version of the host system.

Amanieu · 2025-04-05T20:01:13Z

It's a bit of a grey area since it's not clear how much it is Rust's responsibility to provide builtin symbols that are only used by C code. Arguably the more "correct" approach is to tell users of C code that we only provide symbols for Rust code and that they need to separately add a dependency on libclang_rt or libgcc, but that is a lot of hassle and thing usually just work without it.

I'm not opposed to adding this in libstd for now, but it might be worth looking into a better story for how to handle builtins that are needed by C code but not Rust code (e.g. emulated TLS, clear_cache, enable_execute_stack, etc).

tgross35

Some initial comments, I still need to take a closer look at the version_from* implementations.

tests/run-make/apple-c-available-links/build.rs

tgross35 · 2025-04-04T04:22:04Z

tests/run-make/apple-c-available-links/foo.c

@@ -0,0 +1,15 @@
+int foo(void) {
+    // Use some API that's a lot newer than the host
+    if (__builtin_available(


For my understanding, does linking currently fail if we don't define __isPlatformVersionAtLeast and __isOSVersionAtLeast?

Yup. Commenting out __isPlatformVersionAtLeast fails with:

error: linking with `cc` failed: exit status: 1 | = note: "cc" "/var/folders/0j/tk3sfgz540712zgqd1hrry0m0000gn/T/rustcddlAYt/symbols.o" "<2 object files omitted>" "<sysroot>/lib/rustlib/aarch64-apple-darwin/lib/{libstd-*,libpanic_unwind-*,libobject-*,libmemchr-*,libaddr2line-*,libgimli-*,librustc_demangle-*,libstd_detect-*,libhashbrown-*,librustc_std_workspace_alloc-*,libminiz_oxide-*,libadler2-*,libunwind-*,libcfg_if-*,liblibc-*,liballoc-*,librustc_std_workspace_core-*,libcore-*,libcompiler_builtins-*}.rlib" "-lSystem" "-lc" "-lm" "-arch" "arm64" "-mmacosx-version-min=11.0.0" "-L" "$BUILD/aarch64-apple-darwin/test/run-make/apple-c-available-links/rmake_out" "-o" "main" "-Wl,-dead_strip" "-nodefaultlibs" "foo.o" = note: some arguments are omitted. use `--verbose` to show all linker arguments = note: ld: warning: object file ($BUILD/aarch64-apple-darwin/test/run-make/apple-c-available-links/rmake_out/foo.o) was built for newer 'macOS' version (15.2) than being linked (11.0) Undefined symbols for architecture arm64: "___isPlatformVersionAtLeast", referenced from: _foo in foo.o ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

library/std/src/sys/platform_version/darwin/mod.rs

tgross35 · 2025-04-08T23:49:00Z

library/std/src/sys/platform_version/mod.rs

@@ -0,0 +1,12 @@
+//! Runtime lookup of operating system / platform version.
+//!
+//! Related to [RFC 3750](https://github.com/rust-lang/rfcs/pull/3750), which


Cc RFC author @ChrisDenton just so you know this module exists

library/std/src/sys/platform_version/darwin/tests.rs

tgross35 · 2025-04-08T23:59:18Z

library/std/src/sys/platform_version/darwin/compiler_builtins.rs

+//! In Rust's case, while we may provide a feature similar to `@available` in the future, we will
+//! probably do so as a macro exposed by `std` (and not as a compiler builtin). So implementing this
+//! in `std` makes sense, since then we can implement it using `std` utilities, and we can avoid
+//! having `compiler-builtins` depend on `libSystem.dylib`.


Could you mention why we need this as an extern symbol now, before we have the public API?

This would also be a good place to clarify that we aren't making any guarantees about the availability of these symbols and it's possible we remove them in the future for whatever reason.

Could you mention why we need this as an extern symbol now, before we have the public API?

I've rewritten the section a bit.

Making guarantees about the availability warrants discussion though: Let's say I went and removed this code from curl-sys after this PR lands. If Rust later removed these symbols, users of curl-sys would encounter linker errors again.

That is, without some sort of guarantee of the continued availability of these symbols, they're basically useless.

What are your thoughts?

tgross35 · 2025-04-09T00:03:31Z

library/std/src/sys/platform_version/darwin/compiler_builtins.rs

+// SAFETY: The signature is the same as what Clang expects, and we export weakly to allow linking
+// both this and `libclang_rt.*.a`, similar to how `compiler-builtins` does it:
+// https://github.com/rust-lang/compiler-builtins/blob/0.1.113/src/macros.rs#L494
+#[cfg_attr(not(feature = "compiler-builtins-mangled-names"), unsafe(no_mangle), linkage = "weak")]


Do we need the compiler-builtins-mangled-names config here? I don't really know why that feature is exposed.

I'm not sure actually, I just sorta tried to make it do the same as what happens when using the compiler_builtins::intrinsics! macro.

Perhaps libstd can be compiled with compiler-rt instead, in which case we wouldn't need to export these symbols?

madsmtm · 2025-04-09T18:43:50Z

Thanks for the review so far. I've answered or fixed your comments in separate commits, to make it easier for you to review (if you're already halfway through a second review). I can squash once everything is ready.
@rustbot ready

rustbot assigned Amanieu Mar 25, 2025

madsmtm changed the title ~~Add __isOSVersionAtLeast and __isPlatformVersionAtLeast symbols~~ Add __isPlatformVersionAtLeast and __isOSVersionAtLeast symbols Mar 25, 2025

madsmtm mentioned this pull request Mar 25, 2025

Implement __isPlatformVersionAtLeast and __isOSVersionAtLeast rust-lang/compiler-builtins#794

Closed

This comment has been minimized.

Sign in to view

rustbot added the O-apple Operating system: Apple (macOS, iOS, tvOS, visionOS, watchOS) label Mar 25, 2025

madsmtm force-pushed the apple_os_version_check branch from 3908474 to 721f8eb Compare March 25, 2025 20:21

rustbot assigned tgross35 and unassigned Amanieu Apr 3, 2025

madsmtm mentioned this pull request Apr 4, 2025

Support "zippered" macOS binaries #131216

Open

madsmtm force-pushed the apple_os_version_check branch from 721f8eb to a0061ac Compare April 4, 2025 11:52

madsmtm mentioned this pull request Apr 4, 2025

How do we handle availability? madsmtm/objc2#266

Open

This comment has been minimized.

Sign in to view

Add __isOSVersionAtLeast and __isPlatformVersionAtLeast symbols

19cccaf

Allows users to link to Objective-C code using `@available(...)`.

madsmtm force-pushed the apple_os_version_check branch from a0061ac to 19cccaf Compare April 4, 2025 12:13

madsmtm added a commit to madsmtm/objc2 that referenced this pull request Apr 4, 2025

Fix available! macro when running in "Designed for iPad" mode

e1c7b20

Based on findings in rust-lang/rust#138944, we were previously incorrectly falling back to the product version of the host system.

tgross35 requested changes Apr 9, 2025

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 9, 2025

madsmtm added 2 commits April 9, 2025 20:22

Remove dependency on Cargo from apple-c-available-links test

ab0c005

Rename compiler_builtins.rs to public_extern.rs

71ae9c8

madsmtm added 2 commits April 9, 2025 20:28

Indent plist test and add comment

d59cac3

Make it clearer why we provide extern symbol

f81d430

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add `isPlatformVersionAtLeast` and `isOSVersionAtLeast` symbols #138944

Add `isPlatformVersionAtLeast` and `isOSVersionAtLeast` symbols #138944

madsmtm commented Mar 25, 2025 •

edited

Loading

rustbot commented Mar 25, 2025

rustbot commented Mar 25, 2025

This comment has been minimized.

Amanieu commented Apr 3, 2025

tgross35 commented Apr 3, 2025

This comment has been minimized.

Amanieu commented Apr 5, 2025

tgross35 left a comment

tgross35 Apr 4, 2025

madsmtm Apr 9, 2025

tgross35 Apr 8, 2025

tgross35 Apr 8, 2025

madsmtm Apr 9, 2025 •

edited

Loading

madsmtm Apr 9, 2025

tgross35 Apr 9, 2025

madsmtm Apr 9, 2025

madsmtm commented Apr 9, 2025 •

edited

Loading

Add __isPlatformVersionAtLeast and __isOSVersionAtLeast symbols #138944

Are you sure you want to change the base?

Add __isPlatformVersionAtLeast and __isOSVersionAtLeast symbols #138944

Conversation

madsmtm commented Mar 25, 2025 • edited Loading

Motivation

Solution

Testing

rustbot commented Mar 25, 2025

rustbot commented Mar 25, 2025

This comment has been minimized.

Amanieu commented Apr 3, 2025

tgross35 commented Apr 3, 2025

This comment has been minimized.

Amanieu commented Apr 5, 2025

tgross35 left a comment

Choose a reason for hiding this comment

tgross35 Apr 4, 2025

Choose a reason for hiding this comment

madsmtm Apr 9, 2025

Choose a reason for hiding this comment

tgross35 Apr 8, 2025

Choose a reason for hiding this comment

tgross35 Apr 8, 2025

Choose a reason for hiding this comment

madsmtm Apr 9, 2025 • edited Loading

Choose a reason for hiding this comment

madsmtm Apr 9, 2025

Choose a reason for hiding this comment

tgross35 Apr 9, 2025

Choose a reason for hiding this comment

madsmtm Apr 9, 2025

Choose a reason for hiding this comment

madsmtm commented Apr 9, 2025 • edited Loading

Add `isPlatformVersionAtLeast` and `isOSVersionAtLeast` symbols #138944

Add `isPlatformVersionAtLeast` and `isOSVersionAtLeast` symbols #138944

madsmtm commented Mar 25, 2025 •

edited

Loading

madsmtm Apr 9, 2025 •

edited

Loading

madsmtm commented Apr 9, 2025 •

edited

Loading